Formal aspects of classifying and selecting business services

This paper uses the term “service” for a service instance, and the term “agent” for an agent who provides or consumes a service. We consider real-life or business services (e.g., business process outsourcing, software development service involving human experts). We distinguish business from computational (e.g., Web or grid) services based on the fact that business services lack the typical inputoutput structure of computational services. For example, one can model a temperature service as one that takes a zipcode as input and produces the current temperature as output. By contrast, it would not help to model a software development service as one that takes a “business problem” as input and produces a suite of “software modules” as output. First, it is clearly beyond the scope of current practice to create formal classes or a type system of business problems and software modules. Second, business services are not invoked but are engaged, and would rarely take single-shot inputs and produce single-shot outputs. Third, business service providers would offer a continuum of expertise along which they can provide effective services. For example, a provider who is good at payroll management may also be able to provide retirement plan management, in contrast with the temperature service example above, which has no other function. Fourth, the selection of business services relies on the agents’ evaluation of previous engagements. Service selection inherently considers instances (runtime), not types (design-time). A service can be judged along many different dimensions in an empirical basis. Since agents are autonomous,